1. Field of Invention
This invention relates to the field of object oriented application and operating systems development, and more particularly, to methods and systems supporting the evolution of object interfaces in a distributed object programming environment.
2. Background of Invention
Client-server computing is the predominant model for the management of computing resources, typically on a network of distributed computers. Servers are computers and application programs executing thereon that provide various functional operations and data upon request. Clients are computers and applications that request such services. While clients and servers may be distributed in various computers on a network, they may also reside in a single computer, with individual applications providing client or server functions, or both.
In a client-server system based on a object oriented development environment, a server implements and manages the functionality of a collection of objects. An object consists of some state, and the interface of an object defines the methods, along with the parameters for the methods, to manipulate the state of the object. A client is code that invokes the methods of an object to manipulate the object.
In a distributed object programming environment, a client invokes an object through an object reference, without having information as to where the invoked object resides in the system, that is, without having specific information about the computer where the invoked object is stored or where it is running. Rather, the client passes the object reference through an object request broker (ORB) that locates the server, and passes back any output from the server to the client. To the user, the client and server, and any group of distributed objects, behave transparently as an integrated application, even though the objects may be distributed in various computer systems. One standard for a distributed object programming environment is the Common Object Request Broker Architecture (CORBA), specified by the Object Management Group (OMG).
In the CORBA environment, for the ORB to correctly handle requests, it must have access to the interface definitions of each of the objects it handles. The interface definitions can be made available to the ORB in one of two ways. First, the interface definitions can be directly incorporated into stub routines that represent object methods. Stubs implement proxy objects in the client. To invoke a server object, a client invokes a method on the proxy object for the server object. The stub routine of the proxy object communicates with the ORB to transmit a request to the ORB. In this manner, a client can specify to the ORB the desired operation of the server object, since the interface of the server object is coded into the client. This process provides for static type checking of object definitions for clients written in programming languages such as C++. The client cannot access through its stubs, objects whose interfaces were not included in the stubs when the client was created.
Second, the interface definitions can be persistently stored in an interface repository, from which the ORB may dynamically access the interfaces definitions. With an interface repository, a client may invoke objects dynamically, without having information about the objects when the client is defined. When the client makes such an invocation, the client may access the interface repository to obtain the method signature of the invoked method. The client requires the method signature to construct a well-formed request to the object server and to receive the results of the operation. The ORB may also use the method signature to dynamically type check the parameters of the invocation. In the interface repository, the interface definition of an object comprises a description of the operations the object provides, along with the parameters of each operation, the exceptions it may raise, and additional context information. Each interface definition is itself stored as an interface definition object having operations that manipulate the underlying interface information. For example, an interface definition object for the interface of a given server object will return to a client a description of the interface in response to a request.
As stated above, a client invokes an object by first obtaining an object reference. The client can invoke on the object reference a method to obtain another object reference to the interface definition object in the interface repository that handles the interface definition of the desired object. When the client has the interface of the object, it may invoke any of the methods or attributes defined in the interface.
Under the existing CORBA specification (OMG Object Request Broker 2.0 Interface Repository RFP, OMG TC Document 94-11-7, available by anonymous ftp from omg.org), an interface repository must be coherent, meaning, in part, there is only one interface definition object in the interface repository for each type of object. As stated above, each object has an interface; the interface is described by a declaration in an interface definition language file, such as in the IDL defined by the OMG in TC Document 93-12-43. Each interface declaration has a scoped name. Two objects are of the same type if their interface declarations have the same scoped name. This is required to ensure the interface definition objects, which have the name given in the interface declarations, can be uniquely resolved. As the resolutions are based on type names, if there are two interface definition objects associated with a given type of object, name collision will result.
While this architecture ensures correct identification of objects with stable interfaces, it hinders the more realistic model of system development where object interfaces evolve over time. The evolution of object interfaces is a normal aspect of most systems, and thus it is desirable for the interface repository to support interface evolution.
For example, in a desirable system installation there may be two co-existing environments, a deployment environment, and a development environment. In the deployment environment, objects and their interfaces are stable and unchanging. This is necessary to ensure that the behavior of each object is consistent, thoroughly tested, and known to all clients. In the development environment, however, the object interfaces are continually being improved and updated. These two environments must be kept separate so that client invocations in the deployment environment, where the client expects a particular interface for an object, do not invoke the development version of the object, which may not behave as expected by the client. However, when the development version of the object is stable, it is necessary to place it in the deployment environment for use by all clients.
The problem is that on a single system with a single interface repository, there is currently no easy way to separate the deployment and development environments so that multiple objects of the same type are represented by different interface definition objects. Thus, to differentiate development and development objects, the development objects must be distinct types, from the deployment object, having their own interface definition objects. Otherwise, if the interface of an object is updated, with methods added or deleted, existing clients holding an object reference would malfunction, since these clients would expect the previous interface of the object.
More importantly, in order to install a new object interface, it is most desirable to have both object interfaces for the current deployed and updated development objects operating at the same time, with some clients using the current interface, and some clients running the new interface. This allows a smooth transition between interfaces. However, an interface repository operating merely according to the OMG specifications does not allow multiple interface definition objects for a single object type. When requested to insert a second interface definition object where there already exists a first interface definition object for a given type of object, such an interface repository would either enter the second interface definition object and remove the first, or would reject the request as invalid. If the interface repository did allow the insertion of the second interface definition object, any later client request to resolve an interface by an object name would return an ambiguous result.
In response to this problem the CORBA standard suggests the use of multiple interface repositories to insulate the development environment from the deployment environment. This approach severely limits the ability of the object developers to thoroughly test development objects with existing common resources, or existing client objects in the deployment environment. To test with existing clients, the deployed objects would have to be duplicated in the development environment, resulting in greater requirements for system resources.
In addition, in order to install a new or updated object interface with separate interface repositories for development and deployment, the deployment interface repository must be shutdown, and the new interface installed, replacing the old one. This may impose unacceptable operating burdens on the system, and is not possible in large-scale systems that must run continuously, such as banking systems, or online transaction processing systems.
Accordingly, it is desirable to provide an improved system that allows a single interface repository to maintain multiple interface definition objects for a given object type, while providing correct interface identification and type checking for object requests.